其他
我们的 CMDB 模型是不是都错了?
来源:https://url.cn/5za1nt0
大家有没有想过,我们过去做的CMDB模型都是错的?也许真的错了,可以往下看看。
当前CMDB的模型问题:
首先是思考的深度不够,当今很多CMDB的模型还是聚焦在底层资源。这个底层资源指的一部分是IaaS层的资源管理,另一部分是PaaS层中间件的资源管理。到上层应用这块,其实它的模型表述特别简单,只有一些应用的基本信息。 第二个要讲的问题是无应用视角。今天我们创建管理了这么多资源对象,但不知道是给谁用的,其实真正的着力点是应用。这个我将其总结为无应用层的理解力。 模型的动态性不强。每个模型对象调整它的属性或者关系的时候,在传统数据库里技术端的特点带来的代价特别高。我把模型的动态性抽象成两个维度,第一是模型对象之间在CI级别的动态性,第二个就是实例级。 第四个问题是场景的过度设计。我认为场景是可以预设的,但是细粒度的模型会带来很大的管理负担。有时候会把场景考虑得过于复杂,导致这里面的模型管理后续负担特别重。从简到繁很容易,但是从繁到简很难。 技术限制想象力。受CMDB平台技术本身的能力限制,导致无法扩展这个模型。 欠缺IT架构思考力。我要讲的是从业务架构到应用架构再基础架构。业务架构中还包含了基础设施架构和数据架构。弄清楚这三者的关系后,就能表达出在每一层架构上所带来的本质上的关系连接到底是什么。
面向管理层的ITSM流程。在很多传统企业里面,CMDB还是要为ITSM的流程做好数据支撑服务。 面向执行层的DevOps过程。端到端整个IT交付过程需要完整的元数据,特别是应用层面的元数据。
面向IaaS和PaaS设计,能够管理底层的一切资源。 状态控制借助运维流程自动化完成。 CI的维护要深度使用自动发现,而不是人工维护。 资源信息必须能为上层应用提供服务。 必须满足基础资源的CI管理需要。
提供统一的应用元数据管理能力,和应用类型无关。 核心诉求是应用生命周期管理。 以应用为中心,而非基础资源为中心。 从应用资源的角度构建起与IT资源的弹性关系。 为应用资源、动作、状态的统一管理提供支撑。 以统一的基础资源层CMDB作为基础。 核心场景就是持续交付。
部署资源是一次应用部署所依赖的资源,一般又称本地资源,比如说主机Host、程序包等等。 服务资源是应用运行依赖的资源,一般有称之为附加资源(来自于12factor),比如说应用的服务接口、应用依赖的PaaS资源、应用依赖的应用资源等等。 场景动作是资源其上附加的动作描述,是资源的管理方法。
新一代CMDB的资源模型框架:
最底下的层次其实应该叫做部署资源,主机只是其中的一种。 服务运行过程中起了哪些运行实例、这些实例进程在哪些主机上,主机延伸出来就是IP列表。组件实例有两种,一种是自有实例,当程序运行的时候需要的应用包实例化。一种是依赖实例,就是将依赖组件实例化。 自有服务是自己启动的服务对外提供的时候以怎样的方式暴露出去。依赖服务则是运行时还关联了哪些服务。
应用层和PaaS对象都要深刻理解服务、实例和主机之间的层次关系,并且要精确表达。